Search the Community

Construction of the custom desk is complete! It just needs electrical work! Electrical work is done! Pictured above, the current (as of Dec 2020) mockup of my end goals for this project. I've been working on this project on and off since around June of 2015... I initially first appeared on Page 6 of the Simpit Repository where I showed off some really nice hardware I'd collected for the project. The goal is to create a controller using real instruments to provide readouts of orbital data, temperature, fuel, electricity, and other critical values. The controller will have joysticks and toggle switches and other controls to command the in game vessel. I'm using this project as an opportunity to force myself to learn C programming, and as a furthering of my electronics hobby. While this thread has a LONG way to go to catch up with my progress, I'll work on it over time. INSTRUMENT PANEL PROGRESS STATUS DESIGN HARDWARE SOFTWARE Assembly: Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Analog Resource Meters 0% • Vertical Velocity Meter 90% • 0% • Radar Altimeter Tape Meter 80% • 0% • DSKY Numeric Readouts 10% • DSKY Units Readouts: ------- ------- ------- Diode ROMs ------- Address Decoders 75% • 25% • 0% •/• DSKY Annunciators 90% • 75% • 0% • DSKY Keypad 90% • 90% • 0% • Delta V Carriage Meter 25% • 0% • 0% • Navball Controller: ------- ------- ------- 400Hz Sine Gen ------- 115vac Amplifier ------- Synchro Emus 25% • 0% • 5% • AUX Data Display 25% • 0% • 0% • Velocity Readout 95% • 0% • Attitude Rate Meters 50% • 0% • 0% • Bezels 10% • 0% • ------- As of September 9, 2024, the desk is fully completed! Desk -- CONTROLLER PROGRESS STATUS Not yet officially started, but many individual components and designs have been established, including the support frame. The control panel, fortunately, is a much simpler build electronics wise. It's mostly machining panels and mounting hardware. Solder all the bits together, add some communication to the instrument panel's main controller, and that's it! Part of why this has taken so long, is it's not only a learning process, but I've split my time with other projects. My custom mechanical keyboard was built to work with this Kerbal controller build, and will actually slot into the controller! The number pad magnetically detaches, so when my keyboard tray is extended, I have full use of the extended keyboard, but with the tray pushed in, I can set the number pad aside, and use only the core keyboard! This is the button that started it all. I was inspired by how AWESOME this button looked, and how big and red and "Aborty" it could potentially be! The Instrument panel enclosure is a re-purposed Harris Stereo 5 console that was saved from the local AM radio station. You can see several instruments here. On the right is my analog vertical velocity meter, and in the middle, my FDAI. The Flight Director-Attitude Indicator, more commonly known around these parts as a navball, is a real awesome find! I'm in the process of building a controller for it, but that is a daunting task... It requires nine 28 volt amplitude modulated sinusoidal outputs that are controlled by multiplying DACs, and a 115 volt sinusoidal reference source to provide both power and synchronization for all the 9 other signals. This is the keypad I made for my "DSKY", inspired by the DSKY (DiSplay KeYboard) of the Apollo Guidance Computer (AGC). It normally lights green, but can flash red if there is an alarm condition... Such as the "I'm about to pop like an overheated popcorn kernel" condition. My throttle lever (as well as the keys for my DSKY keypad) were salvaged from an old video effects controller board. I have a LOT of these relegendable, backlit push buttons, in two different sizes. My analog meters are inspired by the edgewise meters used in the Apollo Command Module, Lunar Module, and Space Shuttle. I'm taking the extra effort to print proper scales that use the Futura typeface that NASA used, and follow an overall design that visually resembles the Apollo instruments. Likewise, Tape Meters were also used as instruments on Apollo, and even more so in the first revision of the Space Shuttle, before the glass cockpit upgrades. Tape meters have a long tape on spools. The numbers scroll passed a stationary pointer, the opposite of what an analog meter does, where the pointer moves over a fixed scale. This allows very large scales to be depicted, limited only by tape length. The meter I have will be reprinted with numbers corresponding to the radar altimeter. This is the complete DSKY. I'm currently working on it, and getting it to the point where I can control all the LEDs right now. Current progress has all the large numeric LEDs controlled by MAX7219 controller chips, and the small 7 segment display and one of the three alphanumeric displays is currently functional. https://www.youtube.com/watch?v=8Cwm_xQZsFo https://www.youtube.com/watch?v=LwXZKIfvEkI https://www.youtube.com/watch?v=1Wlv3oyobcg Flashy, isn't it! I've been making diode ROMs to decode characters for some of the LEDs. These cost me literally nothing but time to make, and they satisfy my interest in basic digital circuits. I also rather find I enjoy three dimensional free form circuitry! So yeah... I'm enjoying this part! In all honesty, I really should have started this post back then! I was just collecting parts back in those days, and always said I'd start a dedicated thread when I began assembling things... The Simpit Repository is now up to 23 pages at the moment I'm typing this... It just grew to incredible proportions, and a few times I felt a little bad for dominating the thread with build posts (that really belonged here), but at the same time, I knew my work was showing other people how to do things, and keeping the Repository frequently in the lime light. It just grew to a size that felt too big to abandon, and too big to move the content. I'm starting this post, because I think this build HAS started moving at an accelerated pace, and It should have a dedicated place. I'll build this post up gradually, to cover not only the new content, but to consolidate the content I posted in the Simpit Repository here as well, so the entire build process is properly detailed. I had debated whether I should move content (remove from the Simpit Repository, and replace it here), but I think that'd be unfair to those who replied or were inspired by that content. I'll eventually consolidate everything here, but I'll leave my old posts at the Repository alone. as for new posts, I'll still post at the repository, but I'll no longer post massive multi-image mega build posts... I'll keep my posts there a bit more basic, and put the details all in this post. I'll still offer my knowledge to answer questions people have at the repository. That won't change. It's just silly that I've taken THIS LONG...

After attempting to determine frame rate loss and unnecessary lagging, I have been able to identify that a large portion of issues are being related to the physics engine running through the GPU and the utilization of said GPU will become choked if the perceived framerate exceeds what the engine is calculating in comparison to the GPU. This could be part of the engine to ensure that the engine physics can't run away with GPU utilization and cause damage or overheating on the cards. Full utilization can happen in the game with smaller vessels and when out of Kerbin, but why would the utilization drop when needing more resources due to the number of part, physics calculations, etc. Is this something that is being looked into or are we expected to see this resolve with the future patches and updates? Currently running these specs: AMD Ryzen 9 5900X 12-Core Processor 3.70 GHz EVGA 3080ti 12GB 64 GB DDR4 3200 MHz Ram Please let me know if there are any tips or if there is any other information required.

My idea is to make a enclosed cockpit for kerbal space program. It's going to be a 2 seater and I'm going to build a full control panel. This is what i have done so far. Latest progress photo. Link to simpit's imgur album This is the old simpit before I redesigned it. Link to old simpit's imgur album Here is the link to software being developed for the simpit. https://github.com/Krewmember/External-MFD I hope you guys like it and I will keep you updated as I make progress.

Hello Everyone, I looked up to the developers show case yesterday but one thing ravages me THE HARDWARE REQUIREMENTS OF THE NEW KSP 2.As the graphics are awesome so it may be a problem for many AMD and Intel low end processors and graphics card like GT 730 or GT 710.Will KSP 2 run on low end system like mine(for reference) I3 9100F GT 1030 16GB ddr4 ram. Thanks

I got an awesome new gaming laptop to play KSP with, but it has poor battery life. So, I went and bought a new Maxoak 50000mAh power bank to use with it. It was going fine until it kept shutting itself off while I played KSP. If I wanted to play KSP, I'd have to lower my rig's GPU to low power mode, or else it would trip the power bank. I looked at what happens whenever I did this, and apparently the battery rapidly alternates between being charged and not being charged while on higher performance modes. It would be stable, but the Maxoak is programmed to automatically shut itself off if it's not charging something. This makes it totally unusable. I went to Reddit with this, and I've had no luck. Does anyone here know how to fix/workaround this?

No longer maintained: I don't maintain this mod any more. @Simpit Team have taken over supporting and working on the mod, please see their new release thread. What does it do? This plugin maintains serial connections to one or more hardware devices. Each device can register to receive information that it explicitly wants to receive (for sending to a display, setting off an alarm, triggering a PC shutdown when your vessel runs out of power, etc). A device can also send commands back to the game (stage your rockets with a big red button, build a custom HOTAS to pilot planes, control your EVAing Kerbals with your treadmill, etc). The plugin comes with a companion Arduino library, to make it easy to get started building interactive Kerbal hardware. No really, what does it do? It lets you build things like this: What does it run on? I officially support and test this plugin with 32- and 64- bit KSP on Windows 10, MacOS and Linux. Previous versions of Windows... probably work, but you're on your own. Most microcontrollers should be supported, but only a few have been thoroughly tested so far. Refer to the Supported Devices page of the documentation wiki for more details. If you're using something different, I'd genuinely love to hear about it. What sort of information can I send and receive? The plugin currently sends: Altitude data (sea level and surface. Velocity data (orbital, surface and vertical). Apsides data (apoapsis and periapsis). Time to next pair of apsides. Resource levels (stock fuels, ore, ablator, etc). Action group status. Target information (distance, and relative velocity). Current SoI. The plugin is able to receive commands to control: Custom action group commands, with full support for Action Groups Extended actions. Regular action groups (staging, abort, RCS etc). Main throttle. Vessel rotation and translation. Wheel steer and throttle. Eventually the plugin will be capable of sending most of the telemetry you'd expect from stock KSP and mods such as KER. It will allow full control of vessels and Kerbals, and some limited interface control. Where can I get it? Search for "Kerbal Simpit" on CKAN. I only support installation of this plugin through CKAN or similar mod managers. The only other automated module manager I'm aware of KSP Mod Admin, but I've been struggling for weeks to get it to run on any of my test systems. If there are others around, I'd love to add support for them. Note for the few folk who tried out prerelease builds: You should probably remove the custom CKAN repo from Settings -> CKAN Settings. I'm not uploading releases there any more, and it will eventually go away. The source code is available from https://bitbucket.org/pjhardy/kerbalsimpit/overview . Binary releases sit in https://bitbucket.org/pjhardy/kerbalsimpit/downloads/ . What else do I need? This mod uses Alternate Resource Panel for all of its resource information. Without it, none of the resource providers will send data. This mod will make use of Action Groups Extended if it's installed. With it, all 250 action groups can be accessed. Without it, only the stock 10 action groups will work. Where can I get the Arduino library? Search for "Kerbal Sim Pit" in the Arduino Library Manager. Its source repository is at https://bitbucket.org/pjhardy/kerbalsimpit-arduino/overview . How can I use it? For full documentation, refer to https://kerbalsimpit-arduino.readthedocs.io/en/stable/index.html Quickstart guide: Install the plugin. Configure the plugin. An example config is in `GameData/KerbalSimpit/PluginData/Settings.cfg.sample`. Either copy that file to Settings.cfg or just launch the game once and let the plugin generate a default config. Refer to the Plugin Configuration page on the wiki for details on how to set up ports. Install the Arduino IDE and install the library. In the IDE, browse to File -> Examples -> Kerbal Simpit. Select the KerbalSimpitHelloWorld sketch and flash it to your board. Run the game again. The plugin will log successful device handshakes to KSP.log. Changelog: Full changelog is available from https://bitbucket.org/pjhardy/kerbalsimpit/src/master/CHANGELOG.md?fileviewer=file-view-default License: This project is licensed under the Simplified BSD License.

Will Kerbal Space Program run well on AMD Ryzen 5 3400g with Radeon Vega 11 Graphics APU? Without a separate graphics card with, 16GB DDR4 2400MHz RAM; 500GB M.2 NVMe SSD; Asus EX-A320M Motherboard?

I have a problem with the CPU temperature in my laptop (it gets hot terribly). I recently installed KSP 1.9 (unmoded) and it worked terribly (high temperature and 5-10 fps), previously I played version 1.4 or 1.3 a few years ago on the same computer and I didn't have this problem even with many mods. What is the reason? High terrain resolution in new versions? I don't know much about hardware, maybe only one core or something works? Thanks. I am using Dell Inspiron 3542 Intel Core i3-4005U 1.7 GB Intel HD Graphics 4400 / GeForce 820M 8 GB RAM

My Mark IIb control panel broke down in the spring due to a careless shortcut, and I have been building and redesigning this one on and off since then. I actually missed 1.5 completely, but finally the hardware is at an acceptable configuration. So, after a few time consuming mistakes, I flew an initial test flight with my Flight Control Mk IIId, and was happy with the result. What started when I looked at the price of a joystick with throttle and thought I could make one cheaper did turn out to be a hobby consuming hundreds of euros and opening a whole new field of learning. When I started, I knew a bit of electrics, barely more than Ohms law and the underlying physics. I had written small pieces of software in a lot of languages, but never looked at the beast known as C. The layout: When I realized I needed to redo the panel, I gave some thought to what functionality I was using at the most, and what I needed to see while I still could see the navball. This meant that the two main LCD displays was kept center top, providing me with whatever information I need at the current stage in flight. Below that analogue gauges showing information I need to be aware of approximate magnitude of without having to read a number. A real time clock is also center, it starts blinking a 'b' once time reach past 10 pm for reasons that should be obvious. The joysticks are placed at a distance that corresponds quite close to how far my hands are when I put them in front of me. I used to have them in the corners, but It turned out that I always was pulling a bit off axis as I had to reach to the side for them. Throttle is by the left hand, as I need attitude and throttle control in conjunction far more often than throttle ans translational control. Below the throttle is a momentary brake, and the big red stage button and its toggle. Toggle switches right upper corner have their functionality lit up either red or green, and as they are rather big I can reach them with either hand. The keypad on right side, on the other hand, is so small I need to focus on it. Apart from time warp control, it is mostly used for tertiary functions, such as science gathering, switching navball mode when I want something else than the default, or cycle camera or craft focus. Lower right corner is a number of rotary knobs. This is partially selectors for SAS mode, cam mode/map/IVA and control panel mode (rocket, aeroplane or rover), partially a set of trimmers for the attitude joystick and engine percentage. The LED display in that area show the value of a trimmer when said trimmer is adjusted. Finally, the big red abort button is well out of reach in case I should hit it accidentally, but easy to hit if I actually need it. As with the stage button, is has a toggle switch that physically disables the circuit when locked. The hardware For this panel I went with an Arduino Due. My previous build used a Mega, but I had instances of it not being fast enough when doing a bit of trigonometry and some square roots for my LCD displays. The Due runs at a native 3.3V, so I had to make a level shift protoboard for those units that run at 5V. The 5V are supplied by an old PC PSU, but given the low demands of the system I can keep said PSU off and just use the 5V 2A always on line. Still, nice to have all the power I can dream of within easy reach. Luckily, KSPSerialIO and Win10 talks just fine with this board, although I also have a CH340G USB to serial adapter connected to Serial1. I finally caved in and bought a crimping tool and proper connectors for my wires instead of soldering bits of header to the wire, and ribbon cables for most of the long connections. The protoboards I use are laid out as breadboards, saving a lot of soldering as well, and the wires on the board are single core. These improvements in manufacturing have been costly, but well worth the investment. Loose wire strands generate a lot of noise, and I had to scrap two protoboards where I could not locate the culprit. I have in recent years started to suffer from farsightedness, a fact I found out by having more and more difficulty soldering said protoboards. When soldering these days I use a magnifying lamp my wife exchanged for a better one (she does needlework), and have a set of reading glasses to go with my contact lenses. The annunciator and toggle status lights are all WS2812B LED strips, which saved me a ton of soldering. They are mounted on the button of 3d printed grids and shine through a layer of PVC slides with the actual print and food wrapping paper beneath to diffuse the light sufficiently. All digital switches are connected to 74HC165 or CD4021 shift in registers, and the rotary selectors are connected to 74HC147 encoders, which in turn are connected to shift registers. The reason for using 74HCxxx IC's is that they run at the Dues native 3.3V, so I did not have to level shift the signal to 5V. That was not the case for the 7seg LED modules, that are bought as units with integrated MAX7219 IC's, or the 4x20 LCD displays and the DS3231 real time clock, both types are 5V I2C connected units. The translational joystick is carried directly from my last control panel, and I am still very happy with it. It consists of a thumb joystick and a small piece of stick between two micro switches for three axis control, in a 3d printed casing. While I do use the twist of my attitude joystick for rotation, I would not like to depend on it for fine control or fast reaction. I use a slide potentiometer for throttle. I spent a bit more to get a fader for a mixer instead of a standard pot, I wore my previous throttle out and had problems with unintended engine ignition. The keypad is made from scratch with push buttons on a protoboard and another 3d printed grid to keep them aligned. There are still quite some empty positions on the keypad for when I get ideas to expand my functionality. The software On this panel, I have several functionalities that cannot be activated through KSPSerialIO, so I turned to kRPC. Unfortunately, while I could make a working Python client for kRPC and it even did some of the computational heavy lifting for the Arduino, I experienced considerable latency. This is surely partially due to my very imperfect implementation of the serial communications, but I knew that KSPSerialIO worked fast and out-of-the-box, once I added __attribute__((packed)) to the packets due to 32-bit architecture of the Due. So in the end I just decided to use both plugins, with kRPC handling complicated, non time dependent operations. First iteration had me send information to an Uno over I2C to send to kRPC, but in the end I connected a secondary serial port and cut the middle man. The Interesting ability of kRPC is to access almost everything in the game. In every vessel I made, I assigned solar panels to action group 1, ladders to AG2, science to AG3, engine mode to AG10 and so on. With kRPC, I just ask nicely to open all solar panels, with the important qualifier that there is no docking port between them and the root part in the three hierarchy. This means that when I carry a station part in my spaceplane and extend the solar panels, the solar panels of the station part does not try to unfold inside the cargo bay. In a similar vein, I have toggles for radiators and cargo bays. Science and repeatable science is on different push buttons, although I need to fiddle a bit with this part of the code: If I carry two goo containers, I only want one to open at a time. The code looks for the smallest storage of electrical charge and ties it to a toggle as well. This means that if I forget to extend my solar panels and a probe goes dead, I have a reserve of power to reactivate it. Admit it, you have been there as well. Communications between the kRPC client and the Due is still the biggest issue in the software. I sometimes get massive timeouts, and I still need to implement fast and reliable transfer from the client to the Due. kRPC can access information about misalignment between two vessels when docking, radio signal strenght, and the life support resources. I would like to have an alarm going of based on that information. On the KSPSerialIO side, there is lots of code reuse. I had made functions to deal with LED displays and the information on the LCDs is mostly carry over. Interesting notes are that I calculate circularization dV during the orbital phase of ascent when in rocket mode, and the deviation from KSC runway in aeroplane mode. I also have distance, relative velocity and approximate expected time of arrival showing up during rendezvous. Code to do While the controller works, there is still lot to be done. I have a 7seg to spare that should show time to maneuver node or rendezvous, and most of the annunciator is not programmed yet. Also, It would be nice to be able to call kRPC autopilot sequences from my panel, I have several standard launchers that could benefit from automated launch. Also, a general clean up of things that work but need polish on the second LCD display, it is not fully utilized yet. Source Code and thanks I finally learned how to use GitHub, so my code is available there for both Arduino and kRPC client. I learned a lot from reading other peoples code on the web, and especially @PeteWasEre have good example of using kRPC. As always, @stibbons is a fountain of knowledge, as well as the kRPC discord. And everybody else in the KSPSerialIO thread.

Hello all, Today I want to share with you our development process of making two control panels and I’ll try to answer your most frequent questions. Me and my friend (Ferrdo_Kerman on this forum) always wanted to build control panel for Kerbal Space Program, so we can have even greater experience while playing this fantastic game. This year we finally had this opportunity and time to make this happen. Ferrdo is very skilled in HW and SW so he is the one who decided which HW do we need, how to put it together and also rewrote the base code that we have used from another project. My job was less technical, I worked on design, box, switches variants and I helped with the soldering of course But let’s start from beginning. 1. Preparation Phase We were inspired by hugopeeters project. He made excellent job and our life much more easier because we didn’t have to start from scratch. So really big thanks and credit goes to him. You can check his project with many details here: I will not go so deep into the details because they are already covered in his project but I will just mention that for the communication with the game we used KSPSerialIO plugin which can be found here: https://forum.kerbalspaceprogram.com/index.php?/topic/60281-hardware-plugin-arduino-based-physical-display-serial-port-io-tutorial-10-06-17/ So we bought our first Arduino mega, cables, basic switches, basic stuff and started on our panels. We mainly bought items from local store with electronics and also from e-bay. 2. First steps Ferdo started on LED bars because we assume that this can be the biggest problem and we wanted to solve this in the beginning. From start we had only bars that are now used as G-Force and Athmosphere indicators. This is how they look from behind also with integrated circuits: Even though it went somehow let’s say a Kerbal way, it was a success! After that we moved to display and basic switches. 3. Display and Cardboard prototype We have continued with display because we wanted to test also basic switches and if they are responding correctly regarding the code. While Ferrdo was working on the display and also adjusting the code, I’ve started with the basic cardboard prototype so we can manipulate with the HW easier. In this stage we have decided that we will use another bars for fuels, mono, power etc., and that we will use these old bars as G-Force and Atmosphere indicators. Because in this phase we already know everything that will be on our control panels I have started designing the panel. 4. Design After some adjustments we ended with final version of our design: I’ve prepared vector files based on this design and one of our colleagues helps us to make a prototype from wood so we can check if everything is OK before we will order final panel made of stainless steel from external company. Everything was OK so we have ordered our steel panels from external company. We haven’t had good luck with the first company and they didn’t do the labels correctly. In fact they were barely visible. Luckily we found another company and they reworked our panels to the final look. This was the most expensive part of our panels and one piece cost us almost 100 euros (because of double work). But when they arrived we were finally happy with the outcome. While we were waiting for steel panels from external company we was soldering all parts for the second panel and I was able to prepare box cases from wood. 5. Another Led bars and finishing touches The set of five LED bars took us some time to finish because there were a lot of soldering and coding work. But finally we were really close to the end and therefore hyped. We went to the local store to buy final LED lights (I think it was 7865th visit of this store :D) and started to mounting everything to the panel. It was a really big mess of cables. We did the final soldering and check and we finally put everything inside the box. After some finishing touches everything was functioning correctly! Everything was a little more complicated as described here because we were learning on the fly You can find the source code to this Arduino project at: https://github.com/ferrdo4/KerbalController Video from action is coming soon!

FOR ROCKET USE ONLY: A Kerbal Sim-pit Build Log A name derived from the first piece I bought, a racing car ignition switch with "FOR RACING USE ONLY" printed across the top. This Project started mid 2016 and while its a matter of months off being in a completed form, like most maker projects, I don't ever think Ill be "Finished" with it Aim My aim is to make a sim-pit that surrounds a keyboard that includes a joystick (microswitch, not POTs) and as many switches and buttons I can. After many months of looking at layouts and design themes, I've settled on going for the most Raster Prop Monitor looking IVA theme I can, basing a lot of my panels on this mod. If you don’t know RPM it adds a fully usable IVA into Vessels and looks so aesthetically pleasing: EDIT: This is actually the command pod from the ALCOR mod The Idea is to go more for fun to use than practical. I want as many missile switches and pointless (but useful) knobs and flashing lights as I can. Basically I really want to go for that Arcade, really fun to use feeling even if its not overly practical. Hardware/Software I'm currently using two Arduinos and coding with Arduino's IDE; Arduino Due Old Arduino Uno knockoff (Freetronics Eleven if anyone cares) Arduino Mega The Due uses the <Keyboard.h> library to emulate button presses to control KSP. Flicking a switch will emulate a keyboard pressing a button, for example, flick the light switch, the Due sends a “U” to the computer. But because the switch can be stuck in the on position, the Due only sends the command when there is a change in state. *** The <Keyboard.h> portion of the project has been scrapped in favour of using Kerbal SerialIO's control functions. This means I have lost some functionality meaning a keyboard is still necessary however there are also a lot of pros of doing it this way. This completely removes the use of the Due. The keyboard emulation may return if the build gets an upgrade/increase in size. *** My KSP uses a mod called Kerbal Serial IO by Zitronen, the mod does nothing to the game but sends data packets to and from KSP to the Arduino via Serial communication. Way too technical for me but once I got mine working, it has infinite potential. I'm able to access data from KSP and either print it or use it as logic for warning lights. Their is infinite possibilities with this thing. I have also been able to get my code working with WIN10 as some people couldn't get the control packets working on windows 10, the bug has been fixed and I am now using the control packet to control KSP. I am using two DuinoTech 128x64 Dot Matrix LCDs as my HUD. Arduino has its <LiquidCrystal.H> library making it so easy to code for the screen. Controlled by four buttons to switch between different data sets relevant to different situations and a neat little protoPCB to make all the wires a lot neater. The whole build is designed on five identical sized panels to allow for easy modular use incase I rebuild the enclosure (thinking about a full seated simulator in the future, maybe) Current Stage Here's a few things I've currently got working Currently Built/Working: Staging Button and Stage lock Switch (Prototype) Toggle Switches emulating keyboard press (Controls SAS, RCS, LIGHTS, GEAR) Dual LCD Heads Up Display with real time Data from KSP (currently only displays speed) Fully implemented as of early 2018 Communication from KSP to Arduino (KerbalSerialIO Mod) with onscreen *LED connection Status indicator Control Packets sent from the Arduino to Kerbal via Kerbal SerialIO LED warning Matrix Apollo Style toggle switch guards Laser Cut acrylic panels Custom Enclosure surrounding Keyboard Planned: Custom Enclosure surrounding Keyboard ({Implemented Mid 2018) Joysticks for Attitude and for Throttle (Purchased but not coded and implemented) Controls for LCD Screen changing the Data printed on screen (Implemented early 2018) Possible second LCD for more Heads up Data (Implemented early 2018) Warning LED matrix (Designed and built early 2018) Laser cut acrylic panels with back lit text. (Implemented early 2018, no backlit text.) Possible custom analogue throttle Resources + Credit Ill post all my code but most of it for the Uno is Zitronen’s “Demo16” Code which I have modified. I'll make it clear in the Code what is mine and what was original. All code for my keyboard emulating Due is original. I will comment in code if that changes. *Due removed from build I’ll also make sure to give credit where it's due (in the forum or in the code) as I’m taking a lot of inspiration from other Build logs as I find the fascinating. If I miss something, I apologise. GitHub Code Not really updating anymore, will post final code when done, not posting every iteration Build Logs 18/12/16 For Rocket Use Only First Prototype - 27/12/16 Heads Up Display Screen 27/4/17

After looking in to the internet, I couldn't find any info of what is a good CPU performance in KSP (measured in parts). I just want to know whats the limit of parts your CPU can handle until your timer becomes yellow.

Hi So I just sold off my RX 580 graphics card and is currently using my backup GT610, and I am wondering if there are any ways to make ksp playable on that graphics card without sacrificing too much. I have a watercooled R5 1600x CPU and 16 gigs of ram, and I am currently getting around 4 fps with settings maxed out. What can I do to get my framerate above 30 fps while sacrificing the least amount of detail? Thanks!

Somehow my steam recognizes my joystick (Logitech extreme 3d pro) as a generic gamepad, and is stuck in some weird control profile. I can't seem to delete the profile or reset anything regarding to the joystick. When I open the joystick in the device manager I can see that it's working by testing everything in the properties. I've spent hours trying to figure this out, and haven't found anything pertinent to my situation. Please help me out!

Winter is coming.... ...and I need something to occupy my time while hanging out indoors. Anyone up for working together on a control panel? I'm not a software mod'er, so I need help with actually integrating with KSP, but I am pretty good with electronic design, Raspberry Pi/Aduino, etc... Essentially, I'm thinking of building a small instrument cluster and a cluster of tactile controls (buttons, switches, joystick?) that would sit in an angled enclosure that would sit on your desk. Anyone up for teaming up?

KSP sometimes causes my mac to suffer an error related force shutdown when I attempt to defocus KSP. This has happen once or more per day. I think it is a memory related issue. My specialty is making missiles, not fixing hardware. (But I am great at breaking hardware) Don't quote me on this I come here instead of apple because my warranty ran out and I might have to pay money to get it checked. Plus, they would find where my secret base is. Specs: MacBook Air (11-inch, Early 2015) Processor: 1.6 GHz Intel Core i5 Memory: 8 GB 1600 MHz DDR3 Graphics: Intel HD Graphics 6000 1536 MB

This is my attempt to build a KSP simpit, using Arduino microcontrollers and the KSPSerialIO plugin. It started off small and is currently a lot less small. Current status 20160815: I've been slowly refining my current build. The altitude and vertical speed analogue gauges are now hooked up and working (it only took two years). I have a digital navball that shows current vessel attitude, and have been banging my head against the KSP API trying to work out how to extract the other orbital vectors in a format I can easily render on the ball. I've also started work on machining a new enclosure, this will be more compact and more streamlined and made out of MDF and aluminium composite. It looks awesome in my head, but progress is hampered by my inability to drive a CNC well. Build log entries 20141210 20141230 20150103 20150107 20150107 (2) 20150110 20150116 20150124 20150626 20150629 20150701 20150708 20150711 20150715 20150718 20150721 20150725 20150731 20150801 20150802 20150803 20150806 20150807 20150808 20150812 20150813 20150905 20151101 20151105 20151107 20151115 20151122 20151130 20151207 20151231 20151231 (2) 20160111 20160208 20160710 20160714 20160815 Source code and hardware designs My git repository contains almost all of the details for this build. Design and implementation documentation. Part lists. Source code for the two four arduino microcontrollers. Schematics and board layouts for the printed circuit boards. 2D design files for the laser-cut panels. All under a couple of different open source licences, check LICENSE.md in the source tree. My documentation assumes some basic knowledge of Arduino and digital electronics fundamentals. I didn't bother drawing up schematics for the protoboards containing three switches with pulldown resistors, for example. Hopefully anybody who's completed a few Arduino tutorials or sample projects will get by. First build log This is still very much a work in progress, and there's some obvious controls missing just because I haven't yet figured out the best way to lay them out. These ones got done first because they were the simplest and easiest to lay out, and were a good chance to refine my method for producing the faceplates. After preparing hardware for a few of the sections, I threw together a quick mounting from 10mm perspex and a few M6 bolts. This let me lay down the basic firmware, and the panel's now in active use even though I'm still tweaking it. Because honestly, it's hard to go back to shift and control after that throttle. The panels are made from 3mm perspex, that I've painted and then etched/cut with a laser cutter. There's a longer writeup of how I'm doing those on my blog. I'm using an Arduino Mega 2560 to drive it, with a Mux Shield II to multiplex the inputs, because I was too lazy to string together my own multiplexer. On the software side, I'm using zitronen's KSPSerialIO mod to get telemetry from the game and send commands. My Arduino just communicates with the game over a USB connection. I'm trying to group the controls and readouts in to logical panels. Right now I'm designing attitude control panels, with a couple of small joysticks for translational control as well as toggles for SAS and RCS and strength adjustment. The other section in progress right now uses a couple of analogue gauges for vertical velocity and radar altitude, intended as a landing aid. Further down the line I've got plans in the works to add displays, and then I can start thinking about the size and shape of the final enclosure. Probably. EDIT: This is the panel for managing descents, with the gauges I'm planning on using. It still has the paper backing on the other side, making the lettering a little harder to read in this pic. The scales will both be logarithmic, with the vert speed covering -100 to 100 m/s, and the radar alt going from 0-10000. The switch will toggle between the radar alt showing metres or kilometres. Drawing the scales has been a big challenge, and trying to write efficient code for dealing with logarithms on an Arduino without an FPU even more of a challenge.

I tried the Alt-F9 video recording feature that comes with my new Geforce card software, and found it really easy to use. I was hoping to have a dogfight thread where each participant record some of the videos, but was wondering how common is video recording capability in our community. Most people probably don't have dedicated recording software, and I don't either, so I was wondering how many people have Geforce Experience, and if you tried recording video with it? cuz I think Nvidia cards are pretty common these days.

So after seeing @richfiles, and @stibbons controllers, I've started thinking about maybe (key word maybe) making one of these things. Bear in mind that I have no experience with arduino, or anything other than wiring motors and lights to batterys. Here are my basic ideas. Please tell me if some really aren't possible. Kindle fire for streaming navball from Telemachus 7 segment displays for velocity, altitude, apo/periapsis Joysticks for rotation/translation Toggle switches for SAS, RCS, and etc keypad for action groups, maybe a gutted computer numpad Stage button, one of those buttons with the clear cover for abort action group Master caution, like when my ship reaches critical temperature I don't know if this is possibe, but a terrain alarm, with a button that would light up and yell "terrain!" at you, if the ship is under a certain altitude, going above a certain speed throttle lever ??? I might add more to this list, remember that this is all in my head, and I don't know all that much about electronics, so keep that in mind. The main problem about this is money, as I'm not an adult, and I don't have a job. I would love to make this dream a reality, but we'll see...

I have been working for the past couple of years on a project to create analog gauges that could display some of the game information. Finally, I also developed a program to display the ground tracks and flight profile. Both rely on the mod telemachus and its http server to get the necessary data. Here is the final result. I didn't spend much time on the board itself, as I wanted it to work properly first. The gauges display most ressources of the game (liquid fuel, oxidizer, monopropellant, etc...) and three other parameters: Gs, vertical speed and atmospheric density. I also used two 8 digits 7-segments display for altitude and speed since both these values can vary a lot in the game, it didn't seem appropiate to use the analogue gauges. I recuperated the screen from an old laptop to diplay ground tracks or flight profile. 1) Gauges The core of the gauges is a micro stepper motor X27-168. They are sold as automotive spare parts, mostly for US brands, and quite easy to find. There are quite a lot information about them, especially on Guy Carpenter blog http://guy.carpenter.id.au/gaugette/ The plastic support is 3D printed In order to control the motor, I am using an arduino Uno and the motor driver vid6606. Through my various trials these came to be the best solution. It gives smooth needle movement and is a very flexible solution to add/remove gauges. Each one of those can control 4 motors. The arduino itself is connected by USB to a raspberry pi that sends the http request and calculate the required position for each motor. I had initially tried to control all motors directly via the raspberry pi, but the result wasn't as good: when all values were updated simultaneously, some lag and stutter could appear on the gauges. 2) Ground tracks and flight profile I thought it could be cool to have be able to visualize the ground tracks of a vessel in orbit. Again this is using data pulled from telemachus. Some settings available: However, this is only good in orbit, so I was also inspired by the mod Houston and made a mode to display the flight profile when not in orbit: I initially wanted this to be also diplayed by the rapberry pi, but it wasn't as smooth as when using my laptop, so I finally gave up on that. It was the first time for me to code and I'm sure it could be made much lighter to work well with the rapberry pi though. I had a great time creating all this (more maybe than using it...), I hope you like it too. Let me know what you think!

"Kermander1000" ... another KSP kermand console cockpit thingy ! - Some time ago i wanted to build a control console for a farming simulator to drive tractors and combines, but kermanding a rocket is much more fun. While looking through possible solutions on how to extract data from KSP, i found the ready to use solution : KSPSerialIO (thx @zitronen ) This base frame has carried a flightsim cockpit for many years, hope its capable for space action: I have printed some panels with my 3D-printer, soldered some stuff and written some code into a MEGA. I will build some single modules which will be assembled into a console. Some useful and some senseless displays will be available, some switches do work and some will not. Imagine confused and even tough successful Kerbonauts The 'AnalogGauges2', 'StatusIndicator' and 'MasterIndicatorButton' (AG2, SI, MIND) are fully operational and already succeeded in many missions. The 'ActionGroupControl' (AGC) still needs soldering and coding work to be done. See the following pictures for an impression of my dirty workbench and the modules i'm working on : Could be that all those flashing lights could cause unwanted visual restrictions, i will add a 'No Light'-Switch somewhere

I was wondering which SI prefixes KSP uses in game, and are there any that are skipped? I ask because I know it skips km on your altimeter... (I'm so wrong! i guess I must typically timewarp from LKO to any other body and never noticed Km before! LOL ). It just goes from counting hundreds of thousands of meters and then rolls over into, if I recall correctly, Megameters. After that, I know I've seen Gigameter measurements before in the map views. Does KSP skip any other units than km, or is it just that one unit that gets skipped? I think I recall seeing km used in map view for distance to target, and in standard view to show distance to other objects. I just don't know if km is used for any orbital data... Altitude, Apoapsis, Periapsis, etc. I'm currently in the process of building a digital orbital data readout to fit into a larger scale custom controller for the game. I'd like to keep the units displayed on the controller matching the units displayed on screen. It'd be disorienting to have my readout show 100 km, and the altimeter on screen say 100000 m. I know they are the same, but it's not consistent. I'm occupying myself with continuing my controller build, since my motherboard unfortunately died. It's hard to run KSP to check for units of measure when your computer ain't even functioning. Who knows... Maybe I can get some progress in before the motherboard is repaired/replaced. Adittionally, I also wonder how high do the SI prefixes go? I want my readouts to go as high as they need to go to cover whatever KSP can throw at it... m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym... What's the largest SI prefix KSP actually supports? Are there any other prefixes that KSP tosses out due to the number of digits the altimeter displays? Does the map view use km for any orbital characteristics? I got some nice 14 segment alphanumeric displays that are smaller than my main numeric displays. They are at the end of each relevant numerical display, and will show the correct SI units. I can make the displays support all units (as well as "m.S" and "ΔV"), but it will require more work to add the extra characters. Don't ask me why, but I'm doing a diode matrix ROM for them. It'll be kinda retro, but extra work to have extra characters supported. So... yeah... Just curious if I should plan on supporting them? Thanks in advance. *UPDATE* So, apparently, I am just blind. I never noticed the use of Km as an altimeter measurement, likely cause it occurs in a range that I rarely orbit at (or stay at for long). I can salvage this post though, as now I need to catalog the transition points. Where does KSP switch from m to Km, Km to Mm, Mm to Gm and so on. When I get my motherboard back from being serviced, I'll fire up KSP and check it out, recording the transition points here (unless someone beats me to it).

i am resuming an old project i had but did not document. it was to make a custom ksp cockpit In Real Life and use it to play the game. there was also a mission control. it wasn't that good. my new version will feature a 2 person cockpit, electronic flight instrument system, switches, and buttons etc. there will be an external mission control as well. i will document all my code and mods that i use so that if any one would like to try and build it them self they can. 1. design phase main switch board images SAS mode light board: Control section Engine control section i'm going to add a fuel pump section that will not let my engines start till the fuel pumps are switched on

Here we go again. I built a hardware controller for KSP a year ago using KSPserialIO by zitronen, and was pretty proud of it. However, it had several construction flaws, based on my complete lack of practical knowledge of electronics, and during autumn I started shopping for parts for a replacement. I learned about shift registers and display drivers, and started to build a 7seg readout, but eventually abandoned the idea. I used shift registers to replace the internals of my first controller, but around Christmas it started to give out. I think I burned some pins through excessive drain, and connection became a matter of luck around the advent of 1.0. But then end of semester came pressing, and the project went on back burner until May. Now, however, all exams are past, and I have used my spare time to plan, test concepts, and do the initial woodwork for a second generation flight control panel. Following features are planned. Included features from the go: Separate unit housing dual joystick and two single direction joysticks, throttle and stage button. Included is a rotary knob to adjust strength of RCS as well as attitude. Stage comes with a lock and red/green status LEDs 144 x 80 7" monitor. Holds a max of 10 lines of text, possibility of simple graphics. This is going to replace the HUD1 unit from KER, a long standing ambition. Keypad to specify exactly what will be displayed on the monitor. Toggle control for action groups, SAS, RCR, light, gear, brakes. All toggles have a red/green single LED to indicate status at a glance. Lockable big abort button. Pushbuttons for map, camera, cycle active ship, time warp. These are done by wiring up a USB keyboard controller, as they cannot be controlled by KSPserialIO. Select rocket or atmospheric craft control scheme: This will switch roll and yaw controls, depending on whether I need to fly an airplane (roll on prim joystick), or a rocket (yaw on prim joystick). I might include a separate mode for rovers as well, but they handle pretty well in the rocket config already. Analog gauges for Charge/Current, Fuel, Monoprop and Radar Altitude (3/30 km, log scale) Warning LEDs for speed (slow/fast on descent and ascent), ressources, temp, connectivity. These will be done in red/green single LEDs. Additionally, I have following ideas: Recalibrate joystick on the fly by keypad. (Hard as it does not scale linearly, but doable) Advanced input to the monitor: While I initially just aim for ten default display schemes, I want to customize the output on the fly, using some input scheme. This takes inspiration from the various DSKY projects out there. Rotary knob for selecting SAS control scheme. This hinges on zitronen including it in KSPserialIO Limited autopilot functions, most importantly an optimal descent assistant for vacuum environments. Ascent velocity assist for atmospheric takeoff is desirable, but until I get my hands on a proper drag coefficient calculator for my craft, it remains a wish. A way of calculating the correct orbit to hit a waypoint for a contract, taking into account the rotation of a given body. All of these should provide plenty of time to waste on the project. Shouts should go out to zitronen for making this possible, MrOnak, Mulbin, AmeliaEatYaheart, stibbons, T.A.P.O.R., Sputnix and everyone else who posted a question or an answer in the KSPserialIO thread, as well as the highly inspirational controllers you have shown to the rest of us. Current status: The flight control unit is done. It communicates with the main unit by an old SCART cable, with a few pins to spare. The big red button is staging, and just above it the lock in active position. After this picture was taken, I added a rotary potmeter to scale the input of the joysticks. A view into the unit. You can see the primary and secondary joysticks, as well as the small board routing the input. Originally I wanted to use a VGA connector, but it turned out that I ran out of pins, and had to replace it. The joysticks are artifacts from an ancient age. A gameport joystick for attitude, and a C64 digital joystick for RCS. The monitor. The main panel is build as a frame with bolted modules for easy service and replacement. The individual modules are painted black, and the frame the same grey as the controller. While a lot of modules around here are made of fine looking materials like printed dibond, 3d prints or aluminum, my budget says plywood. Labels will be paper prints in negative, with a bit of touch up around the corners once fitted. The monitor itself has kept me occupied for the last couple of days. The TVout library is very processor intensive and interupts the timer of the Arduino, so I dont think it is going to play particularly nice with KSPserialIO. The solution I use is to use a spare Arduino Uno (clones come at less than €10) and transfer bytes over 8 pins from my Mega to the Uno. I cannot use SPI or I2C as a sane individual because TVout hogs the SPI pins and interrupts I2C, but after some fiddling and a full day of not being able to communicate with my family I got the results I wanted at some 20 FPS, enough for practical use. Last unknown part is the keypad, but glancing at the documentation it does not seems so difficult. Then, it is just a matter of connecting the parts and writing the actual coding af the Arduinos, but that will not require anything but stuff I already have tried before by now.

KSP runs reasonably well for me right now. However, sometimes when I'm in a high part-count scene the frame rate I'm able to draw drops down to about 20fps. This isn't horrible, but it is noticeable. I'm considering upgrading some components. However, I'm not certain if the bottleneck is in the CPU or GPU. Is there a way to easily find out which is the constraining resource? - Garrett